Oracle 19C RAC 集群日志位置变化

您所在的位置:网站首页 oracle trace文件路径 Oracle 19C RAC 集群日志位置变化

Oracle 19C RAC 集群日志位置变化

2023-10-15 17:27| 来源: 网络整理| 查看: 265

作者 | JiekeXu

来源 | JiekeXu之路(ID: JiekeXu_IT)

转载请联系授权 | (微信ID:xxq1426321293)

大家好,我是 JiekeXu,很高兴又和大家见面了,今天分享一篇 Oracle 19C RAC 集群日志位置变化。本文首发于墨天轮,欢迎点击上方蓝字关注我,标星或置顶,更多干货第一时间到达!

有些时候,当数据库出现故障,尤其是当数据库集群无法启动时,这时候就需要查看各种日志来分析定位问题。例如db 的alert 日志,集群日志,ASM 日志,操作系统日志等等,下面来一起看着怎么查找日志,尤其是 12C 以后的数据库集群日志由于新特性而发生变化,更加不好查找。

 

在 oracle 11g 时查看数据库后台日志,一般会使用视图 v$diag_info 或者参数 dump 来查看,当然安装规范的话,也可以直接 cd 查看。

cd $ORACLE_BASE/diag/rdbms/{db_name}/{SID}/trace/alter{SID}.log

SQL> set line456 pages 345 SQL> col NAMEfor a30 SQL> col VALUEfor a88 SQL> select * from v$diag_info; INST_ID NAME VALUE ---------------------------------------- ---------------------------------------------------------------------------------------- 2 Diag Enabled TRUE 2 ADR Base /app/oracle 2 ADR Home /app/oracle/diag/rdbms/Jiekedb/Jiekedb2 2 Diag Trace /app/oracle/diag/rdbms/Jiekedb/Jiekedb2/trace 2 Diag Alert /app/oracle/diag/rdbms/Jiekedb/Jiekedb2/alert 2 Diag Incident /app/oracle/diag/rdbms/Jiekedb/Jiekedb2/incident 2 Diag Cdump /app/oracle/diag/rdbms/Jiekedb/Jiekedb2/cdump 2 Health Monitor /app/oracle/diag/rdbms/Jiekedb/Jiekedb2/hm 2 Default Trace File /app/oracle/diag/rdbms/Jiekedb/Jiekedb2/trace/Jiekedb2_ora_1212.trc 2 Active Problem Count 2 2 Active Incident Count 5 11 rows selected. SQL> showparameter dump NAME TYPE VALUE ----------------------------------------------- ------------------------------ background_core_dump string partial background_dump_dest                 string      /app/oracle/diag/rdbms/Jiekedb/Jiekedb2/trace core_dump_dest                       string      /app/oracle/diag/rdbms/Jiekedb/Jiekedb2/cdump max_dump_file_size string unlimited shadow_core_dump string partial user_dump_dest                       string      /app/oracle/diag/rdbms/Jiekedb/Jiekedb2/trace

 

ASM 日志位置

$ORACLE_BASE/diag/asm/+asm/SID/trace cd $ORACLE_BASE/diag/asm/+asm/+ASM2/trace JiekeXur2:/app/grid/diag/asm/+asm/+ASM2/trace$ls alert* alert_+ASM2.log JiekeXur2:/app/grid/diag/asm/+asm/+ASM2/trace$pwd /app/grid/diag/asm/+asm/+ASM2/trace

当然也可以在 ASM 实例中查看

JiekeXur2:/home/grid$sqlplus / as sysasm SQL*Plus: Release11.2.0.4.0 Production on Fri Dec 18 17:13:19 2020 Copyright (c)1982, 2013, Oracle. All rights reserved. Connected to: Oracle Database11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the RealApplication Clusters and Automatic Storage Management options SQL> showparameter dump NAME TYPE VALUE --------------------------------------------------------------------- ------------------------------ background_core_dump string partial background_dump_dest                 string                            /app/grid/diag/asm/+asm/+ASM2/trace core_dump_dest                       string                            /app/grid/diag/asm/+asm/+ASM2/cdump max_dump_file_size string 100M shadow_core_dump string partial user_dump_dest                       string                            /app/grid/diag/asm/+asm/+ASM2/trace

那么,集群日志位置在哪呢?

cd $ORACLE_HOME/log/hostname/   --指主机名

JiekeXur2:/app/product/11.2.0/grid/log/JiekeXur2$echo $ORACLE_HOME /app/product/11.2.0/grid JiekeXur2:/app/product/11.2.0/grid/log/JiekeXur2$cd /app/product/11.2.0/grid/log/JiekeXur2/ JiekeXur2:/app/product/11.2.0/grid/log/JiekeXur2$ll alert* -rw-rw-r-- 1 gridoinstall 1483455 Dec 18 17:25 alertJiekeXur2.log

下面一起看一下 19C 日志位置变化:

在单机环境下 db alert 日志没有变化,如下位置

cd $ORACLE_BASE/diag/rdbms/{db_name}/{SID}/trace/alter{SID}.log

这样就可以找到 alert 日志以及当前目录下的各种 trace 文件了。

SYS@JiekeCDB>col NAME for a30 SYS@JiekeCDB>col VALUE for a88 SYS@JiekeCDB>set line 456 SYS@JiekeCDB>select * from v$diag_info; INST_ID NAME VALUE CON_ID ---------------------------------------- -------------------------------------------------------------------------------------------------- 1 Diag Enabled TRUE 0 1 ADR Base /opt/oracle 0 1 ADR Home /opt/oracle/diag/rdbms/jiekecdb/JiekeCDB 0 1 Diag Trace /opt/oracle/diag/rdbms/jiekecdb/JiekeCDB/trace 0 1 Diag Alert /opt/oracle/diag/rdbms/jiekecdb/JiekeCDB/alert 0 1 Diag Incident /opt/oracle/diag/rdbms/jiekecdb/JiekeCDB/incident 0 1 Diag Cdump /opt/oracle/diag/rdbms/jiekecdb/JiekeCDB/cdump 0 1 Health Monitor /opt/oracle/diag/rdbms/jiekecdb/JiekeCDB/hm 0 1 Default Trace File /opt/oracle/diag/rdbms/jiekecdb/JiekeCDB/trace/JiekeCDB_ora_6468.trc 0 1 Active Problem Count 0 0 1 Active Incident Count 0 0 1 ORACLE_HOME /opt/oracle/product/19c/dbhome_1 0 12 rows selected.

对于 trace 文件也可以进入到 alert 日志目录下查看,当然,这里还有一种办法查看:

例如查看 lgwr 进程,然后通过进程号查看所在文件路径。

[oracle@JiekeXu~]$ ps -ef | grep lgwr oracle 6597 18080 0 18:03 pts/1 00:00:00 grep--color=auto lgwr oracle 15429 1 0 Dec02 ? 00:01:19 ora_lgwr_JiekeCDB [oracle@JiekeXu~]$ find /opt -name *15429*.trc /opt/oracle/diag/rdbms/jiekecdb/JiekeCDB/trace/JiekeCDB_lgwr_15429.trc [oracle@JiekeXu~]$ tail -f /opt/oracle/diag/rdbms/jiekecdb/JiekeCDB/trace/JiekeCDB_lgwr_15429.trc ***2020-12-13T10:35:33.746113+08:00 (CDB$ROOT(1)) Adaptive scalableLGWR disabling workers kcrfw_slave_adaptive_updatemode:single->scalable redorate=78013 switch=668 ***2020-12-13T14:04:09.009604+08:00 (CDB$ROOT(1)) Adaptive scalableLGWR enabling workers kcrfw_slave_adaptive_updatemode:scalable->single group0=22646 all=31422 rw=808 single=1436scalable_nopipe=1616 scalable_pipe=1212 scalable=1459 ***2020-12-14T22:00:12.018302+08:00 (CDB$ROOT(1)) Adaptive scalableLGWR disabling workers

“Warning: logwrite broadcast wait time 65287ms” 这个警告是:当存储延迟大于 500ms 时,会记录在 lgwr trace 日志中,这里存储方面应该有问题,需要排查延迟问题,我们生产环境里就出现了这样的现象,这里不再阐述。

 

当然,对于 alert  日志,通过参数 dump 也可查看日志位置。

 

当然 19C ASM 日志位置还是可以通过如下方法查看:

ASM 日志位置没有变化:

/app/oracle/grid/diag/asm/+asm/+ASM1/trace/alert_+ASM1.log

 

不过集群日志位置根据前面提供

cd $ORACLE_HOME/log/hostname/   --指主机名

 

如上图,此目录下已经没有集群日志 alertJiekeXur1.log  了,crsd、cssd、gipcd  等集群进程目录下也没有相关日志信息了,那么集群日志到底在什么位置呢?我们来一起看看吧。

 

在 Oracle 中,各个组件(监听器、数据库实例、各种配置工具)在安装和运行时都会有相应的日志Log和跟踪文件Trace生成。Oracle 11g 之前,这些信息都是零散的分布在 Oracle 组件目录中的。在11g,Oracle推出了ADR(Automatic Diagnostic Repository)的概念,将这些信息统一的列入到其中管理。

 

ADR 包含:trace:每个服务器和后台进程都可以写入关联的 trace 文件。trace 文件在流程的整个生命周期内定期更新,可以包含有关流程环境、状态、活动和错误的信息。此外,当进程检测到严重错误时,它会将有关该错误的信息写入其 trace 文件。

dumps:dumps 是一种特定类型的trace 文件。它通常是针对事件(如事件)的诊断数据的一次性输出,而 trace file 往往是诊断数据的连续输出。

core: core 文件包含一个内存转储,采用全二进制的格式。

Alert Log:告警日志,这个不用多说了吧。

sbtio.log 磁带备份 IO相关日志,TSM,NBU 备份等均会写日志到此文件。sbtio.log 的例子如下:

tail -f /app/oracle/diag/rdbms/orcl/orcl1/trace/sbtio.log SBT-14601 08/21/202019:38:59 remove2.cpp(314): sbtremove2(): Exit tdpoSession() failed, dsmHandle =1, rc = -50 =========================================================== Tracing startedfor: ----------------------------------------------------------- Application Client : TDPO LinuxZ64 Version : 7.1.3.0 =========================================================== SBT-5957010/24/2020 20:00:50 send2.cpp(533): sbtwrite2(): Exit - DSMSENDDATA() failed.dsmHandle = 1

下面我们看一下 ADR 目录结构: 

例如一个 DB_UNIQUE_NAME 和 SID 都是orcl 的数据库 ADR  家目录是:/u01/app/oracle/diag/rdbms/orcl/orcl

 

每个子目录的作用如下:

alert:XML格式的 alert log。

cdump:core 文件。

incident: 多个子目录,其中每个子目录都是针对特定事件命名的,每个子目录只包含与该事件相关的转储。

trace: 后台和服务器进程跟踪文件、SQL跟踪文件和文本格式的alert log。alert Log 包含有严重错误(事件)、管理操作,如启动或关闭数据库、恢复数据库、创建或删除表空间等、自动刷新实化视图时出错、其他数据库事件。

others: ADR home的其他子目录,存储事件包、运行状况监视报告、警报日志以外的日志(例如DDL日志和调试日志)以及其他信息。

 

在 Oracle 12c/ 19c 中,集群日志的位置在 ADR_HOME。$ADR_BASE/diag/crs/hostname/crs,我们可以证实,从 ADRCI  命令行,如下图所示:

TEST1:[+ASM1]/home/grid$ asmcmd -V asmcmd version19.6.0.0.0 TEST1:[+ASM1]/home/grid$ asmcmd showversion ASM version : 19.6.0.0.0 TEST1:[+ASM1]/home/grid$ adrci ADRCI: Release19.0.0.0.0 - Production on Tue Dec 29 11:02:14 2020 Copyright (c)1982, 2019, Oracle and/or its affiliates. All rights reserved. ADR base ="/app/oracle/grid" adrci> adrci> showhome

这里便可以很容易找到各个日志,也能看到集群日志以及各个进程的信息日志,为我们分析问题提供更好的帮助。结合操作系统日志 /var/log/messages 加上 OSW、nmon 等工具一起分析问题效果更佳。

 

下面是 adrci 的一个简单应用,show problems 查看集群中所有的问题,没有问题则显示“0 rows fetched“,

adrci> show problems ADR Home =/app/grid/diag/asm/+asm/+ASM1: ************************************************************************* 0 rows fetched ADR Home =/app/grid/diag/tnslsnr/Jieker1/listener: ************************************************************************* 0 rows fetched

如果集群有问题会显示如下信息,然后按照 problem id 将相关日志打包存到指定的目录,如下是一个简单示例:

ADR Home =/app/oracle/grid/diag/asm/+asm/+ASM1: ************************************************************************* PROBLEM_ID PROBLEM_KEY LAST_INCIDENT LASTINC_TIME --------------------------------------------------------------------------------------------------- ---------------------------------------- 1 ORA 7445 [kghidmp_new] 158689 2020-10-10 10:17:21.841000 +08:00 adrci> sethomepath diag/crs/Jieker1/crs adrci> IPSCREATE PACKAGE PROBLEM 1 Created package 1based on problem id 1, correlation level typical adrci> ipsgenerate package 1 in /tmp Generated package1 in file /tmp/IPSPKG_20201229110539_COM_1.zip, mode complete adrci> exit

 

当然,Oracle 也提供了一些很不错的日志收集工具 TFA、ORAchk、EXAchk 等,更有强大的EM 监控工具。

Oracle Trace File Analyzer(TFA)简单示例如下:

ps -ef | grep -itfa /bin/tfactl diagcollect -all -from ”Jun/19/2018 11:00:00“ -to” Jun/19/2018 14:00:00“ /app/product/11.2.0/grid/tfa/Jieker1/tfa_home/bin/tfactl diagcollect -all -from "DEC/28/2020 09:30:00" -to "DEC/28/2020 11:00:00" --查看 TFA 运行情况 Jieker1:~ # ps -ef| grep -i tfa root 27780 60312 0 09:18 pts/0 00:00:00 grep -i tfa root 66166 1 0 Jul17 ? 01:38:39 /bin/sh /etc/init.d/init.tfarun grid 66652 1 0 Jul17 ? 05:03:19 /bin/sh ./OSWatcher.sh 30 48NONE /app/grid/tfa/repository/suptools/Jieker1/oswbb/grid/archive grid 67873 66652 0 Jul17 ? 00:42:05 /bin/sh ./OSWatcherFM.sh 48/app/grid/tfa/repository/suptools/Jieker1/oswbb/grid/archive root 78089 1 0 Jul17 ? 1-09:42:39 /app/product/11.2.0/grid/jdk/jre/bin/java-Xms128m -Xmx512m oracle.rat.tfa.TFAMain/app/product/11.2.0/grid/tfa/Jieker1/tfa_home --使用 TFA 收集一段时间的日志 Jieker1:~ #/app/product/11.2.0/grid/tfa/Jieker1/tfa_home/bin/tfactl diagcollect -all -from"DEC/28/2020 09:30:00" -to "DEC/28/2020 11:00:00" Collecting datafor all components using above parameters... Collecting datafor all nodes Scanning filesfrom DEC/28/2020 09:30:00 to DEC/28/2020 11:00:00 Collection Id :20201229091823Jieker1 RepositoryLocation in Jieker1 : /app/grid/tfa/repository Collection monitorwill wait up to 60 seconds for collections to start 2020/12/29 09:18:25 CST : NOTE : Any file or directory name containing the string .comwill be renamed to replace .com with dotcom 2020/12/29 09:18:25 CST : Collection Name : tfa_Tue_Dec_29_09_18_23_CST_2020.zip 2020/12/29 09:18:25 CST : Sending diagcollect request to host : Jieker2 2020/12/29 09:18:25 CST : Scanning of files for Collection in progress... 2020/12/29 09:18:25 CST : Collecting extra files... 2020/12/29 09:19:33 CST : Getting list of files satisfying time range [12/28/2020 09:30:00CST, 12/28/2020 11:00:00 CST] 2020/12/29 09:19:33 CST : Starting Thread to identify stored files to collect 2020/12/29 09:19:33 CST : Getting List of Files to Collect ………… 2020/12/29 09:21:17 CST : Zip file size : 8.5MB 2020/12/29 09:21:17 CST : Total time taken : 172s 2020/12/29 09:21:17 CST : Remote Collection in Progress... 2020/12/29 09:21:17 CST : Jieker2:Completed Collection 2020/12/29 09:21:17 CST : Completed collection of zip files. Logs are beingcollected to:/app/grid/tfa/repository/collection_Tue_Dec_29_09_18_23_CST_2020_node_all /app/grid/tfa/repository/collection_Tue_Dec_29_09_18_23_CST_2020_node_all/Jieker1.tfa_Tue_Dec_29_09_18_23_CST_2020.zip /app/grid/tfa/repository/collection_Tue_Dec_29_09_18_23_CST_2020_node_all/Jieker2.tfa_Tue_Dec_29_09_18_23_CST_2020.zip --简单查看日志路径及内容 Jieker1:/app/grid/tfa/repository/collection_Tue_Dec_29_09_18_23_CST_2020_node_all# ls -lrt total 16612 -rwx------ 1 rootroot 1198 Dec 29 09:19Jieker1.tfa_Tue_Dec_29_09_18_23_CST_2020.zip.txt -rwx------ 1 rootroot 1186 Dec 29 09:20Jieker2.tfa_Tue_Dec_29_09_18_23_CST_2020.zip.txt -rwx------ 1 rootroot 8411861 Dec 29 09:20 Jieker2.tfa_Tue_Dec_29_09_18_23_CST_2020.zip -rwx------ 1 rootroot 3257 Dec 29 09:20diagcollect_20201229091823_Jieker2.log -rwx------ 1 rootroot 8545429 Dec 29 09:21 Jieker1.tfa_Tue_Dec_29_09_18_23_CST_2020.zip -rwx------ 1 rootroot 4613 Dec 29 09:21diagcollect_20201229091823_Jieker1.log

 

以上是简单示例,还有更多详细内容可查官方文档,19C 新特性系列中对于 TFA 也有所增强,感兴趣的可自行查看。

 

Oracle ORAchk and Oracle EXAchk

Oracle ORAchk 和 OracleEXAchk 为 Oracle 软件和硬件组件堆栈提供了一个轻量级和非侵入性的健康检查框架。

Oracle ORAchk 和 Oracle EXAchk:

 

在业务受到影响之前自动识别风险和主动通知

基于严重和反复出现的问题运行运行状况检查

针对已知问题,提供有关系统运行状况风险和漏洞的高级报告

使您能够深入研究特定的问题并理解它们的解决方案

使您能够定期安排重复的运行状况检查

在守护模式下运行时发送电子邮件通知和diff报告

将发现集成到Oracle健康检查集合管理器和您选择的其他工具中

在您的环境中运行,不需要向Oracle发送任何东西

 

 

Oracle ORAchk 和 OracleEXAchk 平时没有涉及到,这里也就不在叙述了,更多信息可查看官方文档,今天就到这里了。如果本文对您有一丁点儿帮助,请多支持“在看”与转发,都看到这里了哪怕是一个小小的赞,您的鼓励都将是我写文章最大的鼓励,让我有一直写下去的动力,最后一起加油,奥利给!

 

参考链接:

https://docs.oracle.com/en/database/oracle/oracle-database/19/newft/index.html

https://www.modb.pro/db/41837

 

————————————————————————————公众号:JiekeXu之路墨天轮:https://www.modb.pro/u/4347CSDN :https://blog.csdn.net/JiekeXu腾讯云:https://cloud.tencent.com/developer/user/5645107————————————————————————————

Oracle 12c 及以上版本补丁更新说明及下载方法(收藏版) Oracle 21C 新特性:数据泵相关新特性汇总 使用数据泵导出时遇到 ORA-27054 错误解决办法 案例|RAC 添加表空间误将数据文件放本地处理办法 11g RAC 在线存储迁移实现 OCR 磁盘组完美替换 震惊:Oracle 11gR2 RAC ADG 并没有高可用 如何通过 Shell 监控异常等待事件和活跃会话  我的 OCM 之路|书写无悔青春追梦永不止步 Oracle 19c 之多租户 PDB 连接与访问(三) Oracle 12C 最新补丁下载与安装操作指北 DBA 常用的软件工具有哪些(分享篇)? 深入了解 Oracle Flex ASM 及其优点 Oracle 11g 临时表空间管理 Oracle 每日一题系列合集



【本文地址】


今日新闻


推荐新闻


CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3